1. Field of the Invention
This invention relates to apparatus and methods for monitoring interrupts.
2. Description of Related Art
There is an increasing number of applications in which data is transferred between a transmitter and a receiver as a plurality of data streams over a single logical link. The data streams can be segmented at the transmitter into packets, each of which contains some data from the data streams. Usually, but not necessarily, each packet contains data from only one of the data streams. The packets are then transmitted independently over the link. When the packets are received at the receiver they are reassembled so as to re-form the data streams. Advantages of this system over conventional analogue techniques are that there is no need for a dedicated link or channel to be assigned to each of the data streams; that interference in transmission may affect only some of the packets, leaving some data streams unaffected; and that packets may be routed to the receiver over any available physical link and still combined properly to re-form the data streams even if the packets arrive out of order.
Each packet normally includes control data that allows the packet to be reassembled properly by the receiver. This may comprise data indicating the data stream whose data is included in the packet, and a serial number for the packet so that the packet can be combined in the correct order with others from that data stream. The control data can also comprise error-check data such as a checksum for allowing the receiver to verify that the packet has not been corrupted during transmission.
One application for the above technology is in the delivery of digital video signals to households via cable or satellite links. Digital video streams may be packetized and then broadcast to household receivers. A user of a receiver may then select one of the streams for viewing. The receiver can then reassemble that video stream from the received packets, convert it to a form suitable for input to the user's television and then output the resulting signal to the television. It has been proposed that such systems could offer additional features. These features include the storing of received streams for later viewing, and the displaying of program guides (lists of programs with transmission times) which could be assembled by the receiver from certain transmitted packets.
FIG. 1 shows the transport packet stream syntax specified in ITU-T standard H.222.0, equivalent to ISO/IEC standard 13818-1. (Further detail of the structure is available from the standard itself, the contents of which are incorporated herein by reference). FIG. 1 is equivalent to annex F.O.1 of the H.222 standard. The transport stream 1 comprises a stream of packets, each of which consists of 188 bytes. Each packet has a variable length header illustrated at 2 and a payload which occupies the remainder of the packet. The header has the following structure:
Numberof bitsSignification8Synchronization byte1Transport error indicator1Payload unit start indicator1Transport priority13 Program identification (PID)2Transport scrambling control2Adaptation field control4Continuity counterVariableAdaptation field
The structure of the adaptation field is shown in more detail in FIG. 1.
Data representing video, audio, system information such as program guides and other user data streams can be carried as PES packets, which can be included in the payloads of the transport stream packets. The structure of a PES packet is shown in FIG. 2. FIG. 2 is equivalent to annex F.O.2 of the H.222 standard. Each PES packet comprises a 24 bit packet start code prefix, an 8 bit stream identification, 16 bits indicating the length of the PES packet, an optional variable length PES header and PES packet data of variable length.
FIG. 3 shows that the PES packets together form part of a program stream, whose shown in FIG. 3. FIG. 3 is equivalent to annex F.O.7 of the H.222 standard.
In addition, section data can be carried in the packets. The section data can include information that is to be interpreted by the decoding unit. For example, section data may include: 1. data that is to be assembled by the receiving unit into a program guide indicating the programs that are to be provided on a channel; 2. data that is to be assembled into code that can be executed by an interpreter (an “o- code interpreter”) in the receiving unit; and/or 3. data that is to be assembled into decoding keys to allow the receiving unit to decrypt encoded data transmissions such as pay-per-view video.
The overall structure of an H.222 packet containing section data is summarized in FIG. 4, which shows schematically some important features of the packet. The packet comprises a header 5, an adaptation field 6 and a payload 7. The header includes a payload unit start bit 8 and a program identifier (PID) 9. The payload includes one or more sections 10 and, if the payload unit start bit is set, a pointer field 11 which indicates the offset x to the start of the first new section (the intervening bits of the packet may represent tail data of a preceding section). Each section includes information giving the length of that block, and periodically a section includes CRC (cyclic redundancy check) data for it, in order for the receiver to check that section has been correctly received.
A receiving unit can check that a contiguous group of blocks of data forming a section has been received correctly, by calculating a CRC value for the section once it has been received and comparing the calculated CRC value with the received CRC data or, for example, a preset value. If there is the required match then it is assumed that the data has been received correctly. If there is not the required match then the whole section as received is discarded. Retransmission of the section may then be requested, or the receiver may assume that the incorrectly received section has been lost and continue by receiving the next section. In one such checking method a counter is maintained at the receiver, with an initial value of −1. Every incoming byte is combined in turn with the value in the counter to create a new value. The 4 bytes of CRC data at the end of a section are of the values such that if they and the rest of the section have been correctly received then after those 4 bytes have been combined in turn with the counter the value of the counter will be zero. A final value in the counter that does not match zero indicates that data has been corrupted.
When data is being transported for consumption by a data processor unit it is convenient to use interrupt signaling to alert the data processing unit to events that require prompt action, such as filling of the data buffers between the transport and the data processor. The relationship between the transport and the data processor may be complex, and the interrupt operations between the two may need detailed debugging. However, it is generally very difficult to debug the software on a peripheral such as the transport unit since when running normally there is no way to monitor the instruction pointer or registers at anything approaching real time, and there is no breakpoint mechanism available. Also, debugging an interrupt handler is especially difficult since in a working system it is undesirable to interfere with the execution of the handler.
There is therefore a need for an improved method and apparatus for the handing of interrupts so as preferably to facilitate the debugging of interrupt-based operations.